Server-to-server integrity checking

ABSTRACT

A method performed by a primary server includes receiving integrity criteria and sending a health check request to a secondary server based on the received integrity criteria. The method also includes receiving integrity information from the secondary server and checking the integrity information against the integrity criteria. The method further includes initiating a non-compliance action if the integrity information does not comply with the integrity criteria.

BACKGROUND

Computer servers can handle confidential data and perform criticaloperations. The proper behavior of these servers is essential for theproper functioning of our economy and government. “Primary” servers candepend on “secondary” servers (and on networked peripheral devices) incritical ways. The failure or compromise of a secondary server orperipheral device can cause the failure or compromise of the primaryserver. Therefore, it can be essential to verify the security of thesecondary servers and peripheral devices.

Generally, integrity checks of an endpoint may be applied before accessis granted to a network, in addition to traditional user authenticationand/or authorization. For example, before granting access, a network maywish to check if an endpoint's virus protection program is up-to-date,if the endpoint has downloaded the correct software patches, if theendpoint has any spyware or viruses present, etc. However, theseintegrity checks do not pertain to server-to-server andserver-to-peripheral health checking

SUMMARY

In one implementation, a method performed by a primary server mayinclude receiving integrity criteria, sending a health check request toa secondary server based on the received integrity criteria, receivingintegrity information from the secondary server, checking the integrityinformation against the integrity criteria, and initiating anon-compliance action if the integrity information does not comply withthe integrity criteria.

In another implementation, a system may include a health check verifierincluded in a primary device and a health check agent included in asecondary device. The health check verifier may obtain integritycriteria selected for the primary device, send a health check request toa secondary device based on the integrity criteria, receive integrityinformation from the secondary device in response to sending the healthcheck request to the secondary device, check the integrity informationagainst the integrity criteria, and initiate a non-compliance action ifthe integrity information does not comply with the integrity criteria.The health check agent may send integrity information to the primarydevice in response to the health check request.

In a further implementation, a computer-readable memory havingcomputer-executable instructions may include one or more instructions tostore integrity criteria; one or more instructions to send a healthcheck request to a secondary device based on the stored integritycriteria, one or more instructions to receive integrity information fromthe secondary device, one or more instructions to compare the integrityinformation from the secondary device with the integrity criteria; oneor more instructions to initiate a non-compliance action if theintegrity information from the secondary device does not comply with theintegrity criteria, and one or more instructions to send differentintegrity information to the secondary device in response to a healthcheck request from the secondary device.

In still another implementation, a device may include means for storingintegrity criteria for a primary device, means for sending a healthcheck request from the primary device to a secondary device based on thestored integrity criteria, means for receiving in response to the healthcheck request, integrity information from the secondary device at theprimary device, means for comparing the integrity information from thesecondary device with the stored integrity criteria, and means forinitiating a non-compliance action if the integrity information does notcomply with the integrity criteria.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more implementationsdescribed herein and, together with the description, explain theseimplementations. In the drawings:

FIG. 1 is a diagram of an exemplary network in which concepts describedherein may be implemented;

FIG. 2 is a block diagram of an exemplary network device of FIG. 1;

FIG. 3 is a functional block diagram of an exemplary network device ofFIG. 1;

FIG. 4 is a flow diagram illustrating an exemplary process according toimplementations described herein;

FIG. 5 is a block diagram illustrating exemplary non-compliance actionsof FIG. 4; and

FIG. 6 is a diagram of another exemplary network in which conceptsdescribed herein may be implemented.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements. Also, the following detailed description does notlimit the invention.

Overview

Systems and/or methods described herein may implement health checkingbetween a primary server and a secondary server and/or between a primaryserver and a peripheral device. A primary server can check the securityand health of secondary servers and peripheral devices by using anetwork access control (NAC) protocol run over an appropriate transportprotocol. Secondary servers and peripheral devices may be collectivelyreferred to herein as “secondary devices.” The health check can bemutual (e.g., servers checking each other) or one-sided (e.g., a primaryserver checking a secondary device). In one implementation, the primaryserver may use its own criteria for what constitutes acceptable health.For mutual health checks, the secondary devices may also use their owncriteria for what constitutes acceptable health.

In another implementation, at the end of the health check process, keys(such as public/private key pairs) or other credentials can be exchangedso that the health check can be securely tied to other communicationsbetween the parties to the health check, even if those othercommunications take place over another protocol. The health checkprocess can be ongoing with periodic rechecks or rechecks triggered bychanges in policy or changes in system status.

A “health check,” as the term is used herein, may be broadly interpretedto include any functionality that collects server and/or peripheraldevice integrity data, verifies the integrity data, and/or providesother functions with respect to authenticating and verifying thesecurity of the server and/or peripheral device.

“Integrity criteria,” as the term is used herein, may be broadlyinterpreted to include any information to characterize a health checkwithin a network device (e.g., a server or a peripheral device). Forexample, integrity criteria may include information concerning systemrequirements, such as whether a virus protection program is up-to-dateand/or running with current signatures, whether the network device hasdownloaded the correct software patches, whether the network device isin compliance with respect to operating system versions and/or any otherprograms that may be required or forbidden, whether the network devicehas any spyware or viruses present, etc.

Exemplary Network

FIG. 1 is an exemplary diagram of a network 100 in which systems andmethods described herein may be implemented. Network 100 may include aclient 110, a primary server 120, a secondary server 130, a networkperipheral 140, and a public network 150. A single client 110, primaryserver 120, secondary server 130, and network peripheral 140 have beenillustrated in FIG. 1 for simplicity. In practice, there may be moreclients 110, primary servers 120, secondary servers 130, and/or networkperipherals 140. Also, in some instances, one of primary server 120,secondary server 130, or network peripheral 140 may perform a functionof another one of primary server 120, secondary server 130, or networkperipheral 140.

As shown in FIG. 1, client 110 may connect to a private network 160,which may contain primary server 120, secondary server 130, and networkperipheral 140, via public network 150. Private network 160 may includea local area network (LAN), a private network (e.g. a company intranet),or another type of network. Private network 160 may also includeorganizational components, devices, servers, etc. (not shown in FIG. 1).Public network 150 may include a local area network (LAN), a wide areanetwork (WAN), a metropolitan area network (MAN), a telephone network,such as the Public Switched Telephone Network (PSTN), the Internet, anintranet, other networks, or a combination of networks.

Client 110 may include a device, such as a personal computer, a wirelesstelephone, a personal digital assistant (PDA), a laptop, or another typeof computation or communication device, a thread or process running onone of these devices, and/or an object executable by one of thesedevices. Client 110 may initiate a request, to a component, such asprimary server 120, to access resources within private network 160.

Primary server 120 may include a server device, or a set of serverdevices, that contain information, e.g., network content. In oneimplementation, primary server 120 may take the form of a provider ofnetwork content, such as a file, a web page, an e-mail, an instantmessage, a document, etc. In one implementation, primary server 120 mayretrieve information from and/or provide information to anothercomponent within private network 160 to facilitate a request from client110. For example, in some implementations, primary server 120 may be aweb server, an e-mail server, or a voice-over-Internet-protocol (VoIP)server.

Secondary server 130 may include a server device, or a set of serverdevices, that contain information (e.g., network content), to supplementor assist primary server 120. For example, in one implementation,secondary server 130 may include a file server or a database server thatprovides content to and/or receives information from a web server. Inother implementations, secondary server 120 may include an e-mail serverin communication with another e-mail server or a VoIP server incommunication with another VoIP server.

Network peripheral 140 may include one or more peripheral devices thathave a memory and a central processing unit (CPU) and that maycommunicate with primary server 120. For example, in someimplementations, network peripheral 140 may be a disk array, a harddrive, a printer, a keyboard, a tape drive, a communications deviceand/or another peripheral that could potentially be compromised byunauthorized network access.

Primary server 120 may perform one or more operations or services inresponse to, for example, a request provided by client 110. For example,in one implementation, primary server 120 may receive a request fromclient 110, and may provide authentication of client 110 for access toprimary server 120 and/or private network 160. In some implementations,primary server 120 may need to exchange information with secondaryserver 130 and/or network peripheral 140 to facilitate servicing therequest from client 110.

Primary server 120 may conduct a health check of secondary server 130and/or network peripheral 140 by using a NAC protocol (such as TrustedNetwork Connect Client-Server (IF-TNCCS)) run over a suitable transportprotocol (such as Transport Layer Security (TLS)). Primary server 120may use its own criteria for what constitutes acceptable health andinitiate health checks at pre-established intervals and/or based onparticular triggers (e.g., expiration of a timer or change in systemstatus of the primary or secondary server).

In some situations, secondary server 130 and/or network peripheral 140may also initiate a health check of primary server 120. The health checkinitiated by secondary server 130 and/or network peripheral 140 may beconducted either simultaneously or sequentially with the health checkinitiated by primary server 120. Secondary server 130 and/or networkperipheral 140 may use its own criteria for what constitutes acceptablehealth of the primary server 120.

In the event of a failed health check, the requestor (e.g., primaryserver 120, secondary server 130/network peripheral 140) may perform oneor more non-compliance actions to ensure data security is notcompromised. Non-compliance actions may include, for example, loggingthe event, sending a message to a network administrator, aborting thedata exchange, allowing a partial data exchange, switching to a back-updevice of the non-compliant device, initiating an automated repair ofthe non-compliant device, and/or notifying client 110 of a transactionerror.

Although FIG. 1 shows exemplary components of network 100, in otherimplementations, network 100 may contain fewer, additional, different,or differently arranged components than depicted in FIG. 1. For example,network 100 may include a data transfer device, such as a gateway, arouter, a switch, a firewall, a bridge, a proxy server, or the like. Instill other implementations, one or more components of network 100 mayperform the tasks performed by one or more other components of network100.

Exemplary Network Device Architecture

FIG. 2 is a block diagram of an exemplary network device 200, which maycorrespond to primary server 120, secondary server 130 and/or networkperipheral 140. As shown, network device 200 may include a bus 210, aprocessor 220, a main memory 230, a read only memory (ROM) 240, astorage device 250, an input device 260, an output device 270, and acommunication interface 280. Bus 210 may include a path that permitscommunication among the elements of the device.

Processor 220 may include a processor, microprocessor, or processinglogic that may interpret and execute instructions. Main memory 230 mayinclude a random access memory (RAM) or another type of dynamic storagedevice that may store information and instructions for execution byprocessor 220. ROM 240 may include a ROM device or another type ofstatic storage device that may store static information and instructionsfor use by processor 220. Storage device 250 may include a magneticand/or optical recording medium and its corresponding drive.

Input device 260 may include a mechanism that permits an operator toinput information to the device, such as a keyboard, a mouse, a pen,voice recognition and/or biometric mechanisms, etc. Output device 270may include a mechanism that outputs information to the operator,including a display, a printer, a speaker, etc. Communication interface280 may include any transceiver-like mechanism that enables the deviceto communicate with other devices and/or systems.

As will be described in detail below, network device 200 may performcertain operations. Network device 200 may perform these operations inresponse to processor 220 executing software instructions contained in acomputer-readable medium, such as main memory 230. A computer-readablemedium may be defined as a physical and/or logical memory device.

The software instructions may be read into main memory 230 from anothercomputer-readable medium, such as data storage device 250, or fromanother device via communication interface 280. The softwareinstructions contained in main memory 230 may cause processor 220 toperform processes that will be described later. Alternatively, hardwiredcircuitry may be used in place of or in combination with softwareinstructions to implement processes described herein. Thus,implementations described herein are not limited to any specificcombination of hardware circuitry and software.

Although FIG. 2 shows exemplary elements of network device 200, in otherimplementations, network device 200 may contain fewer, additional,different, or differently arranged additional elements. In still otherimplementations, one or more elements of network device 200 may performthe tasks performed by another one or more elements of network device200.

FIG. 3 is a functional block diagram of a portion of network device 200.As illustrated, network device 200 may include an integrity module 300,which may include a health check agent 310, a health check verifier 320,and a controller 330. For purposes of explaining FIG. 3, functions ofhealth check agent 310 and health check verifier 320 will be discussedin the exemplary context of a health check being initiated by primaryserver 120 and the health check being responded to by secondary server130.

Integrity module 300 may include hardware and/or software associatedwith network integrity processes. In some implementations, integritymodule 300 may include health check agent 310 and/or health checkverifier 320 controlled by controller 330. Integrity module 300 mayreceive and store integrity criteria, provide authentication services(e.g., for a network device 200 and/or a user of client 110), provideintegrity checks (e.g., of a network device 200), provide access control(e.g., to a resource protected by integrity module 300) and/or otherintegrity-related processes. In one implementation, integrity module 300may receive the integrity criteria and/or updates to the integritycriteria from an operator (e.g., a network administrator via inputdevice 260 or communication interface 280). Integrity module 300 mayalso receive integrity criteria and/or updates to the integrity criteriafrom a central management system for multiple servers within, forexample, a private network. Integrity module 300 may further receiveintegrity criteria and/or updates to the integrity criteria fromsubscriptions to one or more third party providers to provide initialconfigurations, notifications of changes, updates, software patches,etc. Integrity module 300 may store (e.g., in main memory 230) theintegrity criteria and/or updates to the integrity criteria.

Controller 330 may include hardware and/or software to controloperations of integrity module 300, health check agent 310, and healthcheck verifier 320. In one implementation, based on the stored integritycriteria, controller 330 of primary server 120 may initiate sending ahealth check request to health check agent 310 of secondary server 130.For example, the integrity criteria may include timeliness requirementsfor software updates, required updates to antivirus data files, or thelike. In another implementation, controller 330 of primary server 120may identify the integrity criteria for analyzing integrity informationreceived from, for example, secondary server 130 and/or networkperipheral 140.

The integrity criteria may also include information regarding whenhealth checks may be required (i.e., health check triggers). In oneimplementation, controller 330 of primary server 120 may initiate ahealth check of secondary server 130 and/or network peripheral 140before a certain type of information (e.g., private information) isexchanged. In another implementation, controller 330 of primary server120 may initiate a health check of secondary server 130 and/or networkperipheral 140 at regular time intervals (e.g., every two minutes), atparticular request counts (e.g., after every 1,000 requests from primaryserver 120), or at random time intervals or request counts. In anotherimplementation, controller 330 of primary server 120 may initiate ahealth check in response to a change in system status (e.g., a change inantivirus settings) or a change in policy (e.g., an increased level ofsecurity for a network).

Health check agent 310 may generally perform procedures to enablenetwork device 200 (e.g., secondary server 130) to respond to a healthcheck request. Health check agent 310 may include hardware and/orsoftware that enable a device to collect and assemble integrityinformation in accordance with one or more NAC protocols. For example,in one implementation, health check agent 310 may be configured togenerally comply with Trusted Network Connect (TNC) architecturepromulgated by the Trusted Computing Group (TCG). Health check agent 310may provide integrity information to a network device 200 (e.g., primaryserver 120) in response to health check requests.

Health check verifier 320 may generally perform procedures when networkdevice 200 (e.g., primary server 120) initiates a health check request.Health check verifier 320 may include hardware and/or software toreceive the results of integrity checks from secondary server 130 andprovide an integrity recommendation to integrity module 300. Integritymodule 300 may grant, limit, or deny data exchanges with secondaryserver 130 based on the integrity recommendation from health checkverifier 320.

If a device (such as secondary server 130 and/or network peripheral 140)is determined to be out of compliance with the integrity criteria,integrity module 300 may initiate a non-compliance action.Non-compliance actions may include, for example, logging the event,sending a message to a network administrator, aborting an existing dataexchange, allowing a partial data exchange, switching to a back-updevice for the non-compliant device, initiating an automated repair ofthe non-compliant server, and/or notifying client 110 of a transactionerror. Non-compliance actions are discussed in more detail with respectto FIG. 5.

In one implementation, integrity module 300 may also initiate anexchange of keys (such as public/private key pairs and digitalcertificates) and/or credentials to initiate subsequent communications(i.e., after the health check) between devices using another protocol.For example, after a successful health check, integrity module 300 ofprimary server 120 may provide authentication keys to secondary server130 and/or network peripheral 140 to initiate a transport layer security(TLS) protocol handshake sequence between primary server 120 andsecondary server 130 and/or network peripheral 140.

While FIG. 3 shows both health check agent 310 and health check verifier320 included in integrity module 300, in other implementations, anetwork device 200 may include just health check agent 310 or healthcheck verifier 320.

Exemplary Process

FIG. 4 is a flow diagram illustrating an exemplary process 400 accordingto implementations described herein. In one implementation, process 400may be performed by a network device, such as primary server 120.Process 400 may begin in response to a request from a client (e.g.client 110) for information from primary server 120. The request mayrequire primary server 120 to exchange private information with anothernetwork device (e.g., secondary server 130 and/or network peripheral140) within private network 160. Assume that the request, in this case,requires that primary server 120 gets information from secondary server130. Before this happens, however, primary server 120 may perform anintegrity check on secondary server 130.

Referring to FIG. 4, integrity criteria may be obtained (block 410). Forexample, integrity module 300 of primary server 120 may receiveintegrity criteria from an operator (e.g., a network administrator) viainput device 260 or from another source as a download from communicationinterface 280. The integrity criteria may be selected to be particularlysuited for a single primary server or for a group of servers within aprivate network. The integrity criteria may include, for example,timeliness requirements for software updates, updated versions ofantivirus data files, and the like. The integrity criteria may alsoinclude information regarding when health checks may be required (e.g.,health check triggers).

A health check request may be sent to a secondary server (block 420).For example, primary server 120 may send a health check request tosecondary server 130. The health check request may be based on theintegrity criteria that are specific to primary server 120. For example,if the integrity criteria for primary server require that a virusprotection program is up-to-date and/or running with current signatures,the health check request can be configured to include a request for onlythat information from secondary server 130. The health check request maybe provided using a NAC protocol, such as IF-TNCCS, run over a suitabletransport protocol, such as TLS.

Integrity information may be received from the secondary server (block430). For example, health check agent 310 of secondary server 130 mayconduct a health check of secondary server 130 in accordance with thehealth check request from primary server 120. Secondary server 130 maycompile integrity information in response to the health check requestand send the integrity information to primary server 120 using protocolsconsistent with the health check request. For example, secondary server130 may gather current software versions, verify that antivirus/spywaresoftware is up-to-date and/or has been run within a certain amount oftime (e.g., within the last 12 hours), etc. Primary server 120 mayreceive the integrity information from secondary server 130.

The integrity information may be checked against the integrity criteria(block 440). For example, health check verifier 320 of primary server120 may compare the integrity information from secondary server 130 withthe integrity criteria stored by the primary server 120. Based on thecheck, it may be determined if the integrity information complies withthe integrity criteria (block 450).

If the integrity information complies with the integrity criteria, adata request may be sent to the secondary server (block 460). Forexample, primary server 120 may send a request to secondary server 130consistent with the client's original request to primary server 120. Therequest to the secondary server may be sent via the same or a differentprotocol than was used for the health check request.

In another implementation, as part of the data request, primary server120 may initiate an exchange of keys (such as public/private key pairsand digital certificates) or other credentials so that the health checkcan be securely tied to other communications between primary server 120and secondary server 130, even if those other communications take placeover another protocol. For example, along with the data request, primaryserver 120 may provision authentication keys to secondary server 130 toinitiate a transport layer security (TLS) protocol handshake sequencebetween primary server 120 and secondary server 130. Thus, theauthentication keys (such as a public/private key pair and digitalcertificate) may be used to both verify integrity (i.e., successfulcompletion of the health check process) and identity (i.e., to initiatesubsequent secure communications between primary server 120 andsecondary server 130 over another protocol).

If the integrity information does not comply with the integritycriteria, a non-compliance action may be initiated (block 470). Forexample, the integrity module (e.g., integrity module 300) of primaryserver 120 may initiate one or more non-compliance actions, such asthose discussed with respect to FIG. 5 below.

FIG. 5 is a block diagram illustrating exemplary non-compliance actionsof block 470. Exemplary non-compliance actions conducted by the primaryserver may include switching to an alternative secondary server 510,generating a logging event 520, sending notification to a networkadministrator 530, aborting an attempted data transmission with thesecondary sever 540, limiting the data exchange with the secondaryserver 550, initiating an automated repair 560, and/or sending anotification to the client 570. The forgoing list of non-complianceactions is not limiting, and other actions may be performed by eitherthe primary server or the secondary server in response to a failedhealth check. The primary server (i.e., the server that determines theintegrity information of another server does not comply with theintegrity criteria) may initiate one or more of the following actionssimultaneously or in a sequence.

Switching to an alternative secondary server 510 may include the primaryserver (e.g., primary server 120) terminating communications with thesecondary server (e.g., secondary server 130) and using an alternativesecondary server to accomplish the desired data exchange, assuming analternative secondary server is available. Communications with thealternative secondary server may begin by primary server 120 initiatinga new health check with the alternative secondary server using, forexample, process 400 of FIG. 4.

Generating a logging event 520 may include the primary server recordingthe information of the non-compliance. The primary server may record,for example, a server identification, time, and nature of the failedintegrity check. The information may be compiled with othernon-compliance events and may be stored, for example, in memory 230and/or storage device 250. Information from non-compliance events may beretrieved by a network administrator and/or sent to another computingdevice at, for example, regular (or non-regular) intervals.

Sending notification to a network administrator 530 may include theprimary server providing a message of a non-compliance event to adesignated address or individual. The message may be provided in one ormore of a variety of formats such as an email, a short message service(SMS) message, an instant message (IM), etc. In one implementation, thenotification message may include information from a logging event. Inanother implementation, the notification message may provide anindication that information of a non-compliance event has been stored onthe primary server.

Aborting the data transmission with the secondary server 540 may includethe primary server not performing the proposed data exchange thatinitiated the health check. For example, if the proposed datatransmission involved exchanging data for an on-line purchase by acustomer, the primary server would not conduct the transaction. Limitingthe data transmission with the secondary server 550 may include theprimary server performing a partial data exchange with the secondaryserver. For example, if the proposed data transmission involvedexchanging data for an on-line purchase by a customer, the primaryserver would allow an exchange of some data (e.g., product pricing,shipping calculations, etc.), but may not permit the exchange of privatecustomer information (e.g., credit card information, billing address,etc.).

Initiating an automated repair 560 may include the primary serversending information to the secondary server to initiate a correction tothe integrity of the secondary server. The automated repair may beconducted in accordance with protocols capable of automaticallyrecovering from server integrity compromises. For example, the primaryserver may indicate files (e.g., antivirus files) that are out-dated. Asanother example, the primary server may initiate repairs by sending asignal to a repair agent that may reside in an isolated area (e.g., avirtual machine) on the secondary server. The repair agent may roll backany undesirable changes, perform any additional changes, determine thepoint of entry, and/or prevent further compromise.

Sending a notification to the client 570 may include the primary serverproviding a message to a client (e.g., client 110) that a requestedaction could not be performed or that the request from the client cannotbe processed. The notification may include an explanation of the error,recommendations of alternative connections and/or a statement to try therequest at a later time.

EXAMPLE

FIG. 6 provides an exemplary network 600 to illustrate an implementationof the systems and methods described herein. Exemplary network 600 mayinclude a private network 610 for an online bookstore. Private network610 may include a web server 620 to provide an interface for onlinecustomers. Private network 610 may also include an inventory server 630to track the bookstore inventory and a customer account server 640 tostore customers' personal information, such as addresses and paymentinformation. A customer may access web server 620 in this example viapublic network 150 to search the bookstore inventory and eventuallypurchase a book. To facilitate the customer's search for a book, webserver 620 may need to solicit information from inventory server 630. Tofacilitate the customer's eventual purchase, web server 620 may need toobtain information from customer account server 640. However, before webserver 620 receives information from either inventory server 630 orcustomer account server 640, it would be beneficial to ensure theintegrity of inventory server 630 and customer account server 640 sothat private data will not be compromised (e.g., so that data will notbe sent to or received from a server that has been compromised by anunauthorized user).

To minimize delays and optimize the customer interface, web server 620may request a health check of inventory server 630 at certain intervals.Assume, for example, that the integrity criteria (e.g., provided by anetwork administrator) for web server 620 may require a health check ofinventory server 630 every three minutes. Thus, at three minuteintervals, web server 620 may send a health check request to inventoryserver 630 based on the network administrator's criteria. Health checkagent 635 residing on inventory server 630 may conduct a health check inaccordance with each health check request and send a reply to web server620. Web server 620 may analyze the integrity information in the replyfrom inventory server 630. As long as the integrity information isacceptable (e.g., within the criteria set by the network administrator),web server 620 may continue to request and receive inventory informationfrom inventory server 630. If the integrity information from a healthcheck is not acceptable, web server 620 may perform a non-complianceaction, such as logging the event, sending a message to a networkadministrator, and/or aborting the inventory request to inventory server630.

To ensure every transfer of customer personal information is secure, webserver 620 may request a health check of customer account server 640prior to every transmission of personal information. Particularly, theintegrity criteria (e.g., provided by a network administrator) for webserver 620 may require a health check of customer account server 640before each customer purchase or before each change to customer accountdata. Thus, web server 620 may send a health check request to customeraccount server 640 based on the network administrator's criteria. Healthcheck agent 645 residing on customer account server 640 may conduct ahealth check in accordance with each health check request and send areply to web server 620. Web server 620 may analyze the integrityinformation in the reply from customer account server 640. If theintegrity information is acceptable (e.g., within the criteria set bythe network administrator), web server 620 may continue to exchange datawith customer account server 640 to complete the customer's purchaseand/or account changes. If the integrity information from the healthcheck is not acceptable, web server 620 may perform a non-complianceaction, such as logging the event, sending a message to a networkadministrator, aborting the customer's transaction, and/or notifying thecustomer of a transaction error.

To further ensure every transfer of customer personal information issecure, customer account server 640 may also request a health check ofweb server 620 prior to every transmission of personal information or atparticular intervals. Thus, account server 640 may send a health checkrequest to web server 620 before responding to a request from web server620 to transmit data. The health check process may then proceed in asimilar manner to that described above.

CONCLUSION

In the systems and/or methods described herein, a primary server (and asecondary server or peripheral device) may be able to useserver-specific criteria to conduct server-to-server and/orserver-to-peripheral health checks. Integrity criteria may be definedfor both the type of integrity information being transmitted and thefrequency of each health check. In contrast with Network Access Controlsystems and health certificates provided by third party servers, systemsand methods described herein permit a primary server to use the primaryserver's own integrity criteria and control health check intervals(including real-time health checks). Also systems and methods hereineliminate the need for a separate certification authority, which canincrease system complexity and decrease trust.

The foregoing description of exemplary implementations providesillustration and description, but is not intended to be exhaustive or tolimit the invention to the precise form disclosed. Modifications andvariations are possible in light of the above teachings or may beacquired from practice of the invention.

For example, while the systems and/or methods described herein have beendescribed primarily in the context of servers and peripheral devices,other network devices, such as routers or gateways, may be used toimplement health checks with device-specific integrity criteria usingthe concepts described herein.

Also, while series of blocks have been described with respect to FIGS. 4and 5, the order of the blocks may be varied in other implementations.Moreover, non-dependent blocks may be implemented in parallel.

It will be apparent that embodiments, as described herein, may beimplemented in many different forms of software, firmware, and hardwarein the implementations illustrated in the figures. The actual softwarecode or specialized control hardware used to implement embodimentsdescribed herein is not limiting of the invention. Thus, the operationand behavior of the embodiments were described without reference to thespecific software code—it being understood that software and controlhardware may be designed to implement the embodiments based on thedescription herein.

Further, certain implementations described herein may be implemented as“logic” that performs one or more functions. This logic may includehardware, such as a processor, microprocessor, an application specificintegrated circuit or a field programmable gate array; or a combinationof hardware and software.

It should be emphasized that the term “comprises” and/or “comprising”when used in this specification is taken to specify the presence ofstated features, integers, steps, or components, but does not precludethe presence or addition of one or more other features, integers, steps,components, or groups thereof.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the invention. In fact, many ofthese features may be combined in ways not specifically recited in theclaims and/or disclosed in the specification.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to theinvention unless explicitly described as such. Also, as used herein, thearticle “a” is intended to include one or more items. Where only oneitem is intended, the term “one” or similar language is used. Further,the phrase “based on,” as used herein is intended to mean “based, atleast in part, on” unless explicitly stated otherwise.

1-22. (canceled)
 23. A method comprising: sending, by a first server, afirst health check request to a second server; receiving, by the firstserver, information from the second server in response to the firsthealth check request; checking, by the first server, the receivedinformation against integrity criteria; receiving, by the first server,a second health check request from the second server; and sending, bythe first server and to the second server, information in response tothe second health check request.
 24. The method of claim 23, furthercomprising: receiving, by the first server, the integrity criteria;storing, by the first server, the integrity criteria; and initiating, bythe first server, a non-compliance action if the received informationdoes not comply with the integrity criteria.
 25. The method of claim 23,where the first server sends the first health check request to thesecond server at one or more predetermined time intervals.
 26. Themethod of claim 23, where the first server sends the first health checkrequest to the second server in response to a trigger.
 27. The method ofclaim 23, further comprising: performing, by the second server, a firsthealth check in response to the first health check request; andperforming, by the first server, a second health check in response tothe second health check request, where the first health check and thesecond health check are performed simultaneously.
 28. The method ofclaim 23, further comprising: initiating, by the first server, anon-compliance action if the information received from the second serverdoes not comply with the integrity criteria, where the non complianceaction includes at least one of: generating a logging event, sending amessage to a network administrator, aborting a data exchange with thesecond server, allowing a partial data exchange with the second server,or initiating a repair of the second server.
 29. The method of claim 23,further comprising: sending, by the first server, a third health checkrequest to a third server; receiving, by the first server, informationfrom the third server in response to the third health check request; andchecking, by the first server, the received information, from the thirdserver, against integrity criteria.
 30. A device, comprising: a memoryto store a plurality of instructions; and a processor to execute thestored instructions to: send a first health check request to a secondserver; receive information from the second server in response to thefirst health check request; check the received information againstintegrity criteria; receive a second health check request from thesecond server; and send, to the second server, information in responseto the second health check request.
 31. The device of claim 30, wherethe processor is further to: receive the integrity criteria; store theintegrity criteria; and initiate a non-compliance action if the receivedinformation does not comply with the integrity criteria.
 32. The deviceof claim 30, where the processor sends the first health check request tothe second server at one or more predetermined time intervals.
 33. Thedevice of claim 30, where the processor sends the first health checkrequest to the second server in response to a trigger.
 34. The device ofclaim 30, where the processor is further to: initiate a non-complianceaction if the information received from the second server does notcomply with the integrity criteria, where the non compliance actionincludes at least one of: generating a logging event, sending a messageto a network administrator, aborting a data exchange with the secondserver, allowing a partial data exchange with the second server, orinitiating a repair of the second server.
 35. The device of claim 30,where the processor is further to: send a third health check request toa third server; receive information from the third server in response tothe third health check request; and check the received information, fromthe third server, against integrity criteria.
 36. A computer-readablememory comprising computer-executable instructions, thecomputer-readable memory comprising: one or more instructions to send afirst health check request to a first server; one or more instructionsto receive information from the first server in response to the firsthealth check request; one or more instructions to check the receivedinformation against integrity criteria; one or more instructions toreceive a second health check request from the first server; and one ormore instructions to send, to the first server, information from asecond server in response to the second health check request.
 37. Thecomputer-readable memory of claim 36, further comprising: one or moreinstructions to receive the integrity criteria; one or more instructionsto store the integrity criteria; and one or more instructions toinitiate a non-compliance action if the received information does notcomply with the integrity criteria.
 38. The computer-readable memory ofclaim 36, further comprising: one or more instructions to send the firsthealth check request to the first server at one or more predeterminedtime intervals.
 39. The computer-readable memory of claim 36, furthercomprising: one or more instructions to send the first health checkrequest to the first server in response to a trigger.
 40. Thecomputer-readable memory of claim 36, further comprising: one or moreinstructions to initiate a non-compliance action if the informationreceived from the first server does not comply with the integritycriteria.
 41. The computer-readable memory of claim 40, where the noncompliance action includes at least one of: generating a logging event,sending a message to a network administrator, aborting a data exchangewith the first server, allowing a partial data exchange with the firstserver, or initiating a repair of the first server.
 42. Thecomputer-readable memory of claim 36, further comprising: one or moreinstructions to send a third health check request to a third server; oneor more instructions to receive information from the third server inresponse to the third health check request; and one or more instructionsto check the received information, from the third server, againstintegrity criteria.